1.0 Field of the Invention
This invention relates to a collaborative derivation of an interface; and in particular, this invention relates to collaborative derivation of an interface and partial implementation of programming code.
2.0 Description of the Related Art
Business applications are often created as a collaborative effort between a business analyst and a developer. The business analyst is typically most skilled in defining business rules to describe the information to enable and support business decisions, while the developer is typically skilled in efficient ways to implement computations in programming languages, somewhat independently of the business context in which such computations will be used. This collaboration is often difficult and error prone because the collaborators have different skill sets and they approach the problem from different perspectives and use different tools. A business analyst might use a spreadsheet or a document that is produced using a word processor to define business rules. The business analyst usually expresses those business rules in natural language such as English. The developer may use an Integrated Development Environment (IDE) such as Eclipse or a tool that facilitates programming composition, such as IBM® (Registered Trademark of International Business Machines Corporation) WebSphere® (Registered Trademark of International Business Machines Corporation) DataStage® (Registered Trademark of International Business Machines Corporation), to write computer programs, and define his logic in a programming language, such as Java® (Registered Trademark of Sun Microsystems, Inc.).
Translating the business analyst's business rules to the logic of the developer's programming language is a collaborative and typically mostly manual process today. For example, suppose a business analyst records the following business rule: “take the average credit risk rating per customer over all time periods and all accounts.” The developer translates this high level description of the business rule into an interface for a software component that implements the business rule and computes the desired value, and returns that value in the appropriate format. This interface includes a set of inputs (for example, customer id, customer accounts, time periods, risk ratings per time periods), and a set of outputs (for example, the average risk rating). The developer typically implements this interface by writing code which computes the values of the set of outputs based on the values of the set of inputs using the programming language. Typically, to create this interface, the developer reads and discusses the meaning of the business rule with the business analyst, searches for the sources that provide the input values, defines the output values, and defines logical steps that make up the implementation.
This process is slowed down by the difference in skills, language and tools used by the collaborators and the oral communication that may be required to synchronize their understanding. Often times these differences introduce a number of opportunities for misinterpretation and false starts, as information expressed by the business analyst in one language and one tool, for example, English and a spreadsheet, respectively, is manually transformed into the language and tool, for example, Java and Eclipse, respectively, of the developer.
An additional challenge is that a business analyst's business experience and technical skills vary from organization to organization, depending on whether the business analyst's experience is from the business or technical side of the organization. The business analyst's knowledge and understanding may even vary within a particular application. The business analyst may be able to specify exact implementation details to compute some information, and may only be able to describe in words how to compute other implementation information. For example, implementation details for a particular requirement may be well known to a business analyst because a function to perform a computation may already exist from a previous use, such as an arithmetic function such as round( ) or abs( ), or an existing custom function that computes the nearest location to a customer's home address. However, for new requirements, the business analyst may only be able to provide a high level textual description of a requirement, such as “take the average credit risk rating per customer over all time periods and all accounts.”
Various conventional technologies provide some level of translation to a technical specification, but tend to focus on the technical user, for example, the developer, and work from technical specifications. For example, some Computer-Aided Software Engineering (CASE) tools and some software modeling tools allow developers to model their applications and generate interfaces in a collaborative environment. The Model-Driven Architecture (MDA) allows a developer to separately model the specification from the implementation on a specific platform. Such CASE tools, software modeling tools and their architectures are aimed at software architects and developers, and focus on the detailed technical specifications for a software application. As a result, such tools typically require a certain level of technical skill to use, for example, knowledge of Unified Modeling Language (UML) diagramming, data structure design and data types. Other tools, such as some graphical editors and some development tools for query building or Extract, Transform and Load (ETL) software development, focus on the user being technically adept in the technology and also typically focus on a single-user.
Therefore, there is a need for an improved technique for automating the collaboration between a business analyst and a developer.